"Context engineering" is the term of the year, and like most terms of the year it's already half-buzzword. Stripped of the hype, it means one concrete thing: feed the model the 200 tokens it actually needs, not 8,000 tokens of noise.

The lazy approach — dump the whole file, the whole repo, the whole conversation into the window and let the model sort it out — fails three ways at once. It costs more (you pay per token), it's slower, and counterintuitively it makes the model dumber: the relevant signal drowns in irrelevant context, and the model latches onto the wrong thing. More context is not more intelligence. Better-selected context is.

The core idea Retrieval decides which documents. Context engineering decides which slice of which document, in what order, within a token budget. It's the layer between "I have the data" and "the model used it well."

The Hardest Case: Context for Code

Q&A over documents is the easy version — chunk, embed, retrieve. Code is harder, because relevance isn't about semantic similarity; it's about dependencies. If an agent is editing auth.js, the files it needs in context aren't the ones that read similarly — they're the ones that auth.js imports and the ones that import auth.js. Miss those, and the agent edits one file and silently breaks three others.

This is what I built Agent-Context for. It walks a project, extracts imports across JS/TS/JSX/TSX/Python/Go, and builds a dependency graph: nodes are files, edges are dependencies. Then it answers the only question that matters before an edit — blast radius: touch this file, what else is affected?

Blast Radius, Compact Enough to Fit in a Prompt

The output isn't a sprawling graph dump. It's a tight context string designed to be injected straight into the prompt before the agent acts:

The injected context string ### GRAPHIFY STRUCTURAL CONTEXT FOR [src/auth.js] - Dependencies (what this file uses): src/db.js, src/utils/crypto.js - Dependents (what relies on this file): src/routes/login.js, src/routes/signup.js, src/middleware/guard.js Rule: If you modify this file, be aware of the blast radius affecting its dependents.

An agent that reads this before editing auth.js knows to check three downstream files. An agent that doesn't will break them and call it done. That entire behavioral difference costs about 200 tokens — versus the thousands you'd burn (and the confusion you'd cause) by pasting all four files in full.

The API Is Deliberately Boring

JavaScript — query the graph import { GraphifyClient } from 'agent-context'; const client = new GraphifyClient('./my-project'); const summary = await client.getGraphSummary(); // { nodeCount: 42, edgeCount: 87, nodes: {...}, edges: [...] } const neighbors = await client.queryNeighbors('src/auth.js'); // dependencies + dependents -> the blast radius

No external dependencies, no service to run. It walks the tree (skipping node_modules, .git, dist, venv), parses imports, and answers neighbor queries. The whole value is in what it chooses not to send to the model.

The General Principle

Code is the sharpest example, but the discipline generalizes to every agent:

Select
pull only the slice relevant to this step — by dependency, recency, or score
Compress
summarize or trim it so the signal survives the token budget
Order
put the most important context where the model attends most — near the instruction

Pair this with retrieval done right (see RAG in production) and a strict grounding contract, and you get answers that are both relevant and honest. Context engineering is the quiet half of that equation — and, not coincidentally, a big part of why some agents feel sharp and others feel like they're guessing.

What I Built

Agent-Context is the code-graph / blast-radius engine, extracted from production. For where context selection sits among the other agent organs, see the concepts behind multi-agent systems; for the broader anti-hype case, the boring infrastructure that actually ships.